Appointment negotiation systems and methods

ABSTRACT

One embodiment of the present disclosure relates to a method that includes sending a negotiating message from a user to one or more invitees using a messaging protocol, the negotiating message comprising one or more plans for a meeting, each plan including a time information and a location information for the meeting. The method further includes receiving, using the messaging protocol, one or more responses from the one or more invitees, the one or more responses indicating an approval or rejection of the one or more plans and determining based at least partially on the one or more responses received from the one or more invitees to book the event based on the received responses from the one or more invitees.

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/254,786, filed Apr. 16, 2014, which claims priority to and is acontinuation-in-part of U.S. patent application Ser. No. 13/831,758,filed Mar. 15, 2013, now U.S. Pat. No. 10,803,424, issued Oct. 13, 2020,which claims the benefit of and priority to U.S. Provisional PatentApplication No. 61/639,746, filed Apr. 27, 2012, the contents of each ofwhich are incorporated herein by reference in their entirety.

BACKGROUND

The present disclosure generally relates to the field of schedulingsystems. The present disclosure relates more specifically to ascheduling system and method incorporating an appointment negotiation.

Most computer-based collaboration tools are project or team-centric,requiring a setup time and limiting user access. Different users may usedifferent applications to manage interaction with other users. Forexample, different users may use different calendar applications (e.g.,Microsoft Outlook, Google Calendar, iCal, etc.) to manage his or hermeetings or appointments, and may use different remote devices (e.g.,desktop, laptop, smartphone, tablet, other mobile device, etc.). Somepeople use e-mail, text messages, or video chat to communicate withother users to reach a consensus on the time and location that isagreeable to everyone. There are many applications that promise toconnect individuals; instead, they keep individuals further apart.

SUMMARY

One embodiment of the present disclosure relates to a method thatincludes sending a negotiating message from a user to one or moreinvitees using a messaging protocol, the negotiating message comprisingone or more plans for a meeting, each plan including a time informationand a location information for the meeting. The method further includesreceiving, using the messaging protocol, one or more responses from theone or more invitees, the one or more responses indicating an approvalor rejection of the one or more plans and determining based at leastpartially on the one or more responses received from the one or moreinvitees to book the event based on the received responses from the oneor more invitees.

Embodiments are directed to a method for receiving from a first user anidentification information of a second user, receiving from a first userthe desire to have a meeting with a second user and determining, by acomputer system, one or more times that the first user and the seconduser can have the meeting based at least partially on comparing thecalendar information of the first user and with the calendar informationof the second user to identify available dates and times for themeeting.

Another embodiment of the present disclosure relates to a method forproviding a scheduling service to two remote devices. The methodincludes receiving a request from a first remote device to generate anappointment request, wherein the request includes two or more possibleappointment times. The method further includes transmitting theappointment request including the two or more possible appointment timesto the second remote device. The method further includes receiving aselection of an appointment time from the two or more possibleappointment times from the second remote device. The method furtherincludes transmitting an indication of the selection of the appointmenttime to the first remote device.

Another embodiment of the present disclosure relates to a method forproviding a scheduling service to a first remote device and a pluralityof second remote devices. The method includes receiving a request fromthe first remote device to generate an appointment request, wherein therequest includes two or more possible appointment times. The methodfurther includes transmitting the appointment request including the twoor more possible appointment times to the plurality of second remotedevices. The method further includes receiving a selection of anappointment time from the two or more possible appointment times from atleast one of the second remote devices. The method further includestransmitting the selection of appointment times to the first remotedevice and receiving a selection of an appointment time from the firstremote device. The method further includes transmitting an indication ofthe selection of the appointment time to the plurality of second remotedevices. The indication may include a vote on each appointment timeidentifying a user preference to each appointment time.

Yet another embodiment of the present disclosure relates to a server forproviding scheduling services to at least two remote devices. The serverincludes a communications interface for transmitting scheduling optionsto the at least two remote devices and receiving user inputs from the atleast two remote devices. The server further includes a processingcircuit configured to manage scheduling services for the at least tworemote devices.

Alternative exemplary embodiments relate to other features andcombinations of features as may be generally recited in the claims.

BRIEF DESCRIPTION OF THE FIGURES

The disclosure will become more fully understood from the followingdetailed description, taken in conjunction with the accompanyingfigures, wherein like reference numerals refer to like elements, inwhich:

FIG. 1 is a block diagram of a computerized system for providing anappointment negotiation service to one or more users, according to anexemplary embodiment.

FIG. 2 is a block diagram of the remote device of FIG. 1, according toan exemplary embodiment.

FIG. 3 is a block diagram of a user app module of the remote device ofFIG. 2, according to an exemplary embodiment.

FIG. 4 is a flow chart of a process for one-to-one scheduling using theappointment negotiation service of the present disclosure, according toan exemplary embodiment.

FIGS. 5A-F are illustrations of example user interfaces generated in theprocess of FIG. 4, according to an exemplary embodiment.

FIG. 6 is a flow chart of a process for one-to-one scheduling includingcounter offering, according to an exemplary embodiment.

FIGS. 7A-D are illustrations of example user interfaces generated in theprocess of FIG. 6, according to an exemplary embodiment.

FIG. 8 is a flow chart of a process for group scheduling using theappointment negotiation service of the present disclosure, according toan exemplary embodiment.

FIGS. 9A-F are illustrations of example user interfaces generated in theprocess of FIG. 8, according to an exemplary embodiment.

FIG. 10 is a block diagram of the scheduling service module of FIG. 1,according to an exemplary embodiment.

FIGS. 11-33 are further example of user interfaces generated by thescheduling service module of FIG. 1, according to an exemplaryembodiment.

FIG. 34 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

FIG. 35 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

FIG. 36 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

FIG. 37 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

FIG. 38 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

FIG. 39 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

FIG. 40 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

FIG. 41 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

FIG. 42 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

FIG. 43 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

FIG. 44 is a user interface screen that may be generated by the systemshown in FIG. 1, according to an exemplary embodiment.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

Before turning to the figures, which illustrate the exemplaryembodiments in detail, it should be understood that the application isnot limited to the details or methodology set forth in the descriptionor illustrated in the figures. It should also be understood that theterminology is for the purpose of description only and should not beregarded as limiting.

Referring generally to the figures, appointment negotiation systems andmethods are shown and described. The systems and methods herein may beused by two or more users for scheduling an appointment, meeting, orevent; negotiating or deciding an appointment time; and otherappointment, meeting, or event decisions, including but not limited toan appointment location, a dial-in number, privacy settings, inviteepriority level (i.e., who should respond to the invite first), etc. Thesystems and methods described herein allows a user to perform such tasksthrough a user application on a remote device. The user application maybe configured to receive and send appointment information, and to syncappointment or meeting information with other applications (such as acalendar application). In one embodiment, a user may use the userapplication to create an appointment invitation to one or more otherusers, and may select one or more possible times for the appointment.The other users may use the user application or another application toaccept, decline, or propose a counter-offer for the appointment.

In one embodiment, the systems and methods herein may be used by twousers to schedule an appointment. A first user may use the userapplication to create an appointment, including two or more possibleappointment times. The appointment and possible appointment times may besent to the second user, who chooses one of the appointment times orsends a counter offer. A scheduling service may be configured to managethe process by sending out alerts to both users about the appointmentand decisions, and by managing a calendar application of each user.

In one embodiment, the systems and methods herein may be used by morethan two users to schedule an appointment. A first user may use the userapplication to create an appointment, including two or more possibleappointment times. The appointment and possible appointment times may besent to a plurality of other users. The other users may select apreferred appointment time, indicate a preference about each appointmenttime, or otherwise. A scheduling service may be configured to receivethe other user selections and provide the user selections to the firstuser. The first user may then select an appointment time based on theuser selections. The scheduling service may be configured to then sendalerts to the other users about the selection and to otherwise managethe scheduling process by managing a calendar application, etc.

In one embodiment, the systems and methods herein may create acloud-based negotiation system that allows two or more users tonegotiate in setting up an appointment, without the users using anothercalendar application or email. A user interface configured to allow theusers to set up and negotiate appointments may be used in place of othercalendar applications or email. Two or more users may set up, negotiate,and finalize an appointment through the use of push notifications only.

Referring generally to FIG. 1, a block diagram of a computerized system100 for providing an appointment negotiation service to one or moreusers is shown, according to an exemplary embodiment. System 100 isshown to include one or more remote devices 102 (e.g., a mobile device)connected to a scheduling system 104 via network 110. Remote device 102may be a mobile device (e.g., mobile phone, PDA, smartphone, etc.)configured to run a mobile application 103 (system 103), according toone embodiment. The plurality of remote devices 102 may connect to anappointment negotiation system 104. Appointment negotiation system 104may provide appointment services as generally described in the presentdisclosure to a remote device 102 and application 103. Appointmentnegotiation system 104 may provide data and user interface services tomobile application 103 of remote device 102. For example, appointmentnegotiation system 104 may provide user interfaces that allow a user toset up an appointment and select appointment times, allow a user toaccept, reject, or provide a counter offer to the appointment andappointment times, or other appointment negotiation activities asdescribed herein. The activities of remote device 102 are shown ingreater detail in FIG. 2. The activities of appointment negotiationsystem 104 are shown in greater detail in FIG. 3.

Appointment negotiation system 104 may receive and transmit data to andfrom remote device 102. For example, appointment negotiation system 104may transmit information to remote device 102 relating to a calendarentry. If a user is to receive an invitation to an appointment,appointment negotiation system 104 may be configured to send theinvitation data along with data that may be used by remote device 102 tocreate an entry on a calendar application of the user. Calendarapplications may be any type of application configured to track a user'sappointments, meetings, and other time-based or calendar-based events.Such examples of calendar applications may include iCal, GoogleCalendar, Microsoft Outlook, etc.

In one embodiment, appointment negotiation system 104 may create acalendar entry to transmit to remote device 102. The calendar entry mayrelate to an appointment and appointment times proposed by another user.Application 103 may be configured to receive the calendar entryinformation and to sync the information with a calendar application ofremote device 102. In another embodiment, appointment negotiation system104 may be configured to receive calendar entry information for acalendar entry from a user input via application 103.

In one embodiment, appointment negotiation service 104 may communicatewith remote device 102 and transmit the appointment data such thatremote device 102 and application 103 manages a calendar application ofthe remote device. In another embodiment, other remote devices may nothave application 103, or may not be a mobile device. In such a case,appointment negotiation system 104 is shown connected to a network 110.Appointment negotiation system 104 may receive information from variouscalendar applications 106 via network 110 for users of remote devices108 (e.g., desktops, laptops, etc.). This may allow a user withoutapplication 103 or a remote device 102 configured to run application 103to interact with appointment negotiation system 104.

Remote device 102 may be configured to connect via a wireless connectionwith appointment negotiation system 104, according to one embodiment.The wireless connection may be a local area network (LAN) connection,wide area network (WAN) connection, or any other type of wirelessconnection. Alternatively or additionally, remote device 102 may connectvia a wired connected or via any other type of connection. Network 110may be a mobile phone network, the Internet, a combination thereof, etc.

Referring to FIG. 2, a more detailed block diagram of remote device 102is shown. Remote device 102 may be used for interaction with appointmentnegotiation service 104 (e.g., for viewing appointment invitations, forcreating an appointment, etc.). Remote device 102 includes a processingcircuit 202 which includes processor 204 and memory 206. Processor 204may be implemented as a general purpose processor, an applicationspecific integrated circuit (ASIC), one or more field programmable gatearrays (FPGAs), a group of processing components, or other suitableelectronic processing components. Memory 206 is one or more devices(e.g., RAM, ROM, flash memory, hard disk storage, etc.) for storing dataand/or computer code for completing and/or facilitating the various useror client processes, layers, and modules described in the presentdisclosure. Memory 206 may be or include volatile memory or non-volatilememory. Memory 206 may include database components, object codecomponents, script components, or any other type of informationstructure for supporting the various activities and informationstructures of the present disclosure. Memory 206 is communicablyconnected to processor 204 and includes computer code or instructionmodules for executing one or more processes described herein.

Memory 206 is shown to include user app module 207 for launching userapplication 103. User app module 207 may be a standalone applicationinstalled on remote device 102 for assisting with the appointmentnegotiation process. Many of the resources for providing user interfacesfor user application 103 may be stored on remote device 102 and theback-end data may be received by user app module 207 from appointmentnegotiation system 104. Referring generally to the later figures,various illustrations of example applications provided by user appmodule 207 are shown.

Remote device 102 further includes a network interface 208 configured tocommunicate with appointment negotiation system 104 via a wirelessconnection. Remote device 102 further includes input devices 210 andoutput devices 212. Input devices 210 may include any input device(touchscreen, telephone keypad, pointer, etc.) that may be used by auser to interact with user app 103. Output devices 212 may includedisplay screens, speakers, and/or any other visual or audio componentsfor providing a user of remote device 102 with feedback such asappointment information as described herein. User interface 214 may beany sensor or other control configured to accept or detect a user inputand to interpret the user input. Remote device 102 may include anynumber or types of input devices 210, output devices 212, and userinterfaces 214 that interact with user application 103 and appointmentnegotiation system 104.

Referring to FIG. 3, the activities of user app module 207 are shown ingreater detail. User app module 207 may be configured to synchronizewith other applications on remote device 102, transmit or receive datafrom the other applications, etc. The activities of user app module 207may be used to support the activities of appointment negotiation system104.

User app module 207 may be configured to synchronize with a calendarapplication at calendar module 302. Calendar module 302 may beconfigured to provide appointment information to a calendar applicationof remote device 102. Further, calendar module 302 may be configured toretrieve calendar information such as a list of appointments, meetings,and events, along with details for each appointment such as a time,attendees, location, or other information. The information may be used,for example, to present a list of available times to a user attemptingto set up an appointment, to determine other conflicts, to view userpreferences, etc. Calendar module 302 may be configured to retrievecalendar information from multiple calendars, and to combine thecalendar information for use as described in the present disclosure. Inanother embodiment, instead of working with information from anothercalendar information calendar module 302 may be configured to manage itsown calendar application for the user.

User app module 207 may further include a contact list module 304.Contact list module 304 may be configured to retrieve a contact listfrom, for example, an address book of the user of remote device 102.Contact list module 304 may provide the user with a list of people toselect to invite to an appointment. Contact list module 304 may furtherretrieve other information related to the people on the contact list(e.g., phone number, email, location, calendar, etc.) that may be usedby the user while setting up the appointment. For example, suchinformation may be retrieved from social media sites (e.g., Twitter,Facebook, etc.), email services (e.g., Gmail, Yahoo! Mail, etc.), apersonal information manager (e.g., Outlook, Exchange, etc.), or anyother source that may be accessible by remote device 102. Contact listmodule 304 may further provide a user interface that allows the user tomanually enter contact information of a user, and may be configured tostore the contact information in database 308.

User app module 207 may further include an invitation module 306configured to provide the user with a user interface for setting up aninvitation. For example, the user interface may allow the user tospecify a name for the appointment, a description of the appointment,proposed appointment times, if the appointment is recurring, or otherinformation. Invitation module 306 may be set up to allow the user tocontextually select and choose appointment times in the setup of theappointment. For example, the user may access a calendar applicationgenerated by calendar module 302 while setting up the invitation, allowthe user to view his or her own schedule to determine ideal appointmenttimes. The contextual selection highlights certain events using coloringor shading.

User app module 207 may further include database 308. Database 308 maybe configured to store user information provided by other users viaappointment negotiation system 104. For example, a user response to anappointment invitation, along with all accompanying data, may be storedby database 308. Referring generally to subsequent figures, the otheruser data displayed to a first user via user app module 207 may bestored in database 308.

User app module 207 may be configured to synchronize with otherapplications as mentioned above. For example, any time a user alterssomething in an application (e.g., calendar, email, etc.), the changemay be synchronized into user app module 207, and vice versa.

One-to-One Scheduling

Referring now to FIG. 4, a flow chart of a process 400 for one-to-onescheduling using the appointment negotiation service is shown, accordingto an exemplary embodiment. Process 400 may be executed by, for example,appointment negotiation system 104 for two users (a first user using afirst remote device and a second user using a second remote device)attempting to set up an appointment.

Process 400 includes receiving a request from the first remote device togenerate an appointment request (step 402). The appointment request maybe generated by a user using user app module 207. The appointmentrequest may generally include a date, a name or title for the meeting, adescription of the meeting, a location, the person being invited, andmultiple proposed times for the appointment. For example, FIG. 5Aillustrates various user interfaces that may be presented to a usergenerating an appointment request via user app module 207. The user maybe presented with a calendar 502 and may select a particular date 504for the appointment. Upon selecting date 504, user app module 207 maypop up a list of possible times for the appointment. The list ofpossible times may be generated based on user availability (determinedusing other calendar information), user preferences, etc. The user mayselect at least two appointment times 508 (e.g., 1 PM, 2 PM, 3 PM, etc.)and then choose collaboration button 510. Upon pressing button 510, theuser may be presented with a user list 514 in a new window 512 topossibly invite to the appointment. User list 514 may be users who alsohave user app module 207 and are capable of negotiating the appointmenttimes via user app module 207. The user may select a user from user list514. Alternatively, if the user wants to invite another user who doesnot have user app module 207, the user may be presented with a window516 including a contact list 518 of other users. In one embodiment,instead of providing displays windows 512, 516 separately, the windowsmay be provided together. After finalizing all appointment details, theuser may send the invitation, and appointment negotiation system 104 mayreceive the invitation and invitation details at step 402. It should beunderstood that while the displays shown in FIG. 5A are shownindependently, the displays might be part of a contextual view providedby user app module 207. In other words, the displays may be part of acalendar application that the user may interact with, instead of beingprovided as a separate application.

Step 402 may further include, at user app module 207, creating acalendar entry for each appointment time of the appointment. Forexample, a calendar entry marking a “tentative” appointment may becreated at 1 PM, 2 PM, and 3 PM.

Process 400 further includes transmitting the appointment request,including the two or more possible appointment times, to the secondremote device (step 404). In one embodiment, if the second remote devicedoes not include user app module 207, the second remote device mayreceive a text message or email with the invitation information. Forexample, FIG. 5B illustrates a sample text message 520. Text message 520includes a description 522 of the appointment and the person sending theappointment, a listing 524 of proposed appointment times, and two links526, 528 or accepting or declining the invitation. Text message 530 mayfurther include a message 530 providing instruction to the user. Theuser may accept or decline the invitation by selecting the appropriatelink 526, 528 and then typing in 1, 2, or 3 to indicate a chosen time.Text message 520 may further include a link 532 that the user may clickto download an application to install user app module 207. Text message520 may further include a link 534 that the user may click to visit awebsite. The website may then allow the user to respond to theappointment invitation. The website may further provide the user with adownloadable file with appointment information that may be used tocreate an entry on the user's calendar application.

In another embodiment, the user without user app module 207 may receivean email with invitation information. The email may include a link to awebsite where the user may accept, decline, or propose a counter offerto the invitation. The email may further include a calendar attachment(e.g., Outlook, iCal and/or Google Calendar attachments) that the usermay use for his or her own calendar application.

In one embodiment, if the remote device does not have user app module207, after the user has finalized the appointment with the first user,the user may enter his or her calendar application credentials.Appointment negotiation system 104 may then provide a display (e.g., ona website) that displays the calendar information of the user from thecalendar application, including a new calendar entry for the newappointment just finalized. The appointment negotiation optionstypically provided on user app module 207 may then be provided via thedisplay.

If the user does have user app module 207, step 404 may includetransmitting the appointment request to the remote device and creating apush notification for the remote device. Further, the appointmentrequest information may be used to populate an entry in a calendarapplication of user app module 207. For example, referring to FIG. 5C, acalendar application 540 is shown after receipt of the appointmentinvitation. The appointment invitation is shown to automaticallypopulate calendar 542 with entries 544, 546. The entries may behighlighted according to various settings of calendar application 540.For example, calendar application 540 may indicate each proposedappointment time as “tentative.” Each appointment time may behighlighted in color (e.g., yellow), shaded, or otherwise distinguishedfrom other appointments on the calendar. Calendar application 540 may beconfigured to determine whether to display each appointment time as itsown calendar entry. For example, entry 548 does not show as a possibleappointment time because the user already has something scheduled, eventhough the appointment time was part of the appointment request. Asanother example, entry 548 may show the possible appointment time, butthe entry may be shaded or include an icon that indicates the conflict.

The user of the second remote device may select an appointment time, anda selection of the appointment time may be received by appointmentnegotiation system 104 (step 406). For example, referring to FIGS. 5C-D,a user may select calendar entry 544 to pop up message 550 of FIG. 5D.The selection of the calendar entry may vary. In one embodiment, theuser may view a calendar entry, and the application may be configured todisplay an “accept” button. The user may then select the button toselect the time, or scroll to another appointment time. The user maythen confirm via button 552 that he or she wishes to select that timefor the appointment.

Step 406 may include receiving a notification that a user has declinedeach appointment time, or the appointment in general. The user may beprompted to suggest another time (see FIG. 6), or to provide a messageexplaining the denial to be provided to the first user.

Process 400 further includes transmitting an indication of a selectionof an appointment time to the first user using the first remote device(step 408). For example, the user of the first remote device may receivea push notification, such as one shown in window 560 of FIG. 5E, thatthe other user has accepted an appointment time. The user may thenconfirm the appointment via button 562 or cancel the appointment (oredit appointment details) via button 564. Alternatively, window 560 maynot include such options, and may simply indicate that the appointmenthas been booked. As another example, the user of the first remote devicemay receive a push notification, such as one shown in window 570 of FIG.5F, notifying the user that the other user has declined the invitation.

Step 408 may further include various activities once the appointmenttime has been set by both parties. For example, calendar entries foreach possible appointment time may be created as described above. Aspart of step 408, user app module 207 may be configured to delete allcalendar entries for unselected appointment times. Further, if theappointment time that was selected had been marked as “tentative”earlier at the first remote device, the status of the appointment timemay be changed to “confirmed” and the display of the calendar entry inthe calendar may turn from yellow to green to indicate the change. Theappointment time status at the second device may be changed to“confirmed” when the second user selects the appointment time, insteadof waiting for confirmation from appointment negotiation system 104.User app module 207 may further be configured to synchronize with othercalendar applications upon the completion of step 408.

Process 400 further includes synchronizing the appointment between thetwo remote devices (step 410). The synchronization allows a change madein the appointment by any user to be automatically applied to theappointment entry of each user, along with providing an accompanyingmessage to the other users regarding the change. Step 410 may includesynchronization with a calendar-based application of user app module 207or any other calendar system (e.g., iCal, Google calendar, Outlook,etc.).

One-to-One Scheduling with Counter Offers

Referring now to FIG. 6, a flow chart of a process 600 for one-to-onescheduling using the appointment negotiation service is shown, accordingto an exemplary embodiment. Compared to process 400, process 600 may beexecuted when the second user wishes to propose a counter offer. Process600 may be executed by, for example, appointment negotiation system 104for two users (a first user using a first remote device and a seconduser using a second remote device) attempting to set up an appointment.

Process 600 includes receiving a request from the first user of a firstremote device to generate an appointment request (step 602) andtransmitting the appointment request, including two or more possibleappointment times to a second user of a second remote device (step 604).Instead of accepting or declining an appointment invitation, the seconduser may provide a counter offer. Process 600 further includes receivinga first counter offer from the second remote device (step 606). Thecounter offer may generally include a list of alternate appointmenttimes to propose to the first user.

For example, referring to display 700 shown in FIG. 7A, the second usermay be presented with a list of proposed appointment times 702, 704,706, along with an option 708 to decline the appointment and an option710 to select another time (e.g., to counter offer). Upon selectingoption 710, the user may be presented with window 720 of FIG. 7B.Display 720 may display a calendar application, and the second user mayselect one or more times 722 from the calendar application. As shown inFIG. 7B, the second user's calendar indicates the user is booked duringthe proposed appointment times, so the user may select 11 AM and 12 PMas alternative times. Referring now to display 730 of FIG. 7C, thesecond user has chosen two alternative times 732 and may send the timesvia option 734 to appointment negotiation system 104 at step 606. Uponsending the counter offer, a user app module 207 may be configured todelete calendar entries that may have been created relating to theoriginal appointment invitation.

Process 600 further includes transmitting the first counter offer to thefirst user of the first remote device (step 608). An example display 736is shown in FIG. 7D that may be presented to the first user. The firstuser may then select an appointment time from the counter offer orprovide a second counter offer to the second user.

In one embodiment, the first user selects an appointment time from thecounter offer. Process 600 includes receiving a selection of anappointment time of the first counter offer from the first remote device(step 610). Process 600 then includes transmitting an indication ofselection of the appointment time to the second remote device (step612). The activities of steps 610, 612 may generally be similar to theactivities of steps 406, 408 of FIG. 4 relating to alerting users viapush notification, updating the status of calendar entries, deletingunselected calendar entry times, synchronizing calendars, etc.

In one embodiment, the first user may instead provide a second counteroffer, including alternative appointment times, to the second user.Process 600 includes receiving a second counter offer from the firstuser of the first remote device (step 614). Process 600 then includestransmitting the second counter offer to the second remote device (step616). The first user and second user may continue to send each othercounter offers until one user either accepts an appointment time of acounter offer or declines the invitation. When the process of counteroffering is complete, the appointment may be synchronized for eachremote device (618) as generally described with reference to step 410 ofFIG. 4.

Process 600 describes an implementation of a counter offer process ifboth users have user app module 207. In one embodiment, if the secondremote device does not have user app module 207, the second user may notbe able to submit a counter offer. In another embodiment, the seconduser may submit a counter offer via a website, via text message, or viaany other electronic medium available to the user.

It should be understood that the displays shown in FIGS. 7A-D are shownby example only, and may be only partial views of the displays that maybe provided by user app module 207. For example, in FIGS. 7C-D, suchdisplays may be displayed over a calendar application, allowing for theuser to interact between the calendar and the displays. In other words,the appointment options as shown in FIGS. 7A-D are presented to the userwithin the context of the calendar application. Such a relationship isshown in greater detail in FIGS. 11-33.

Group Scheduling

Referring now to FIG. 8, a flow chart of a process 800 for groupscheduling using the appointment negotiation service is shown, accordingto an exemplary embodiment. Process 800 may be executed when a firstuser wishes to create an appointment with multiple attendees. Process800 may be executed by, for example, appointment negotiation system 104for multiple users (a first user using a first remote device and atleast two second users using second remote devices) attempting to set upan appointment. While process 800 described a process for groupscheduling, it should be understood that elements as described withreference to one-to-one scheduling (particularly about pushnotifications, creating calendar entries via user app module 207, etc.)may be executed as part of process 800 at each individual remote device.

Process 800 includes receiving a request from the first user of thefirst remote device to generate an appointment request (step 802). Step802 may be similar to, for example, step 402 of process 400 with regardsto setting up an appointment. For example, also referring to FIG. 5A,the first user may simply select multiple users 514, 518 instead of asingle user, and appointment negotiation system 104 may be able toreceive the appointment information and to determine whether theappointment is a one-to-one appointment or a group appointment.

Process 800 further includes transmitting the appointment request,including two or more possible appointment times, to the second users ofthe second remote devices (step 804). If the user does not have user appmodule 207 on his or her remote device, the user may receive a textmessage or email as described with reference to FIGS. 4 and 5B. If theuser does have user app module 207, the user may be sent a pushnotification such as a display 900 shown in FIG. 9A. Display 900 maysimply indicate that the user has been invited to an appointment, andindicates three (or a different number) of possible appointment timesfor selection. The transmission of the appointment request may beprovided in the same manner as described with reference to process 400of FIG. 4. For example, for each second user with user app module 207 onhis or her remote device, step 804 may include generating calendarentries on the user application for each of the appointment times.

A first user may wish to invite more second users to the appointmentafter the initial invitation is sent at step 804, or one or more secondusers may wish to forward the invitation to other users. If so, theinvitation may be sent to other users after step 804, as long as thefinal appointment time for the appointment has not been finalized orselected by the first user. In one embodiment, a first user may send theinvitation to additional second users at his or her choosing. In anotherembodiment, a second user may send the invitation to an additionalsecond user. The second user may or may not seek permission from thefirst user to send the invitation to an additional second user. Theappointment negotiation server may be configured to receive all suchinvitations after the execution of step 804 and to update the firstremote device and each second remote device with information about eachuser as described below.

Process 800 further includes receiving a selection of appointment timesfrom at least one second user of the second remote devices (step 806).For example, referring also to display 910 of FIG. 9B, a second user isshown selecting two possible times (1 PM, 2 PM) for the appointment,that may be sent to appointment negotiation system 104 by pressingbutton 914.

Step 808 may include various sub-steps as part of the process ofselecting appointment times. In one embodiment, the user may simplyselect appointment times that fit the user's schedule (which may bezero, one, two, or more appointment times), and transmit the selectionback to appointment negotiation system 104.

In another embodiment, the user may vote or assign a value to eachoption. For example, the user may rank the appointment times from mostdesirable to least desirable. As another example, the user may vote oneach individual appointment time. The user may indicate, for eachappointment time, if the time is “ideal,” “okay,” “not okay” (e.g., theuser cannot make the appointment), or any other status to associate withthe appointment time.

In one embodiment, the plurality of second remote devices may continueto receive push notifications, or other information, from appointmentnegotiation system 104 at step 806. For example, each time a second usertransmits a selection to system 104, system 104 may in response transmitthe selection to the other second remote devices, updating a status ofthe appointment invitation. For example, referring to display 920 ofFIG. 9C, a second user is shown receiving an indication that anothersecond user has selected two times 922. The user may select a time viabutton 926, decline the invitation via button 924, or perform any otheraction related to the appointment invitation.

In one embodiment, if a second user is unable to make the appointment atany of the given appointment times, the user may provide a counter offerwith additional appointment times. As compared to process 600 of FIG. 6,however, since there are other second users with whom the first user isnegotiating with, the proposed additional appointment times may or maynot be sent to other second users. The additional appointment times may,however, be placed as a calendar entry via user app module 207.

Process 800 further includes transmitting a selection of appointmenttimes to the first user of the first remote device and the plurality ofsecond remote devices (step 808). In one embodiment, each user mayreceive a selection of an individual second user after the user makesthe selection. In another embodiment, step 808 may include waiting untilall second users have responded, and sending an aggregate response tothe all users. In yet another embodiment, step 808 may include waitinguntil a majority or set percentage of second users have responded, mayinclude waiting until one or more “important” users have responded, orotherwise.

If a first user receives second user selections one at a time, the firstuser may select an appointment time to confirm, or may simply continueto wait for more responses. If the first user receives all second userselections at once, the first user may then be prompted to select anappointment time. In one embodiment, appointment negotiation system 104may aggregate all information in a table or chart, allowing the firstuser to view all appointment time information. In another embodiment,appointment negotiation system 104 may suggest one or more appointmenttimes that fits everyone's schedule or fits the most schedules. If theuser receives only a plurality, but not all, of second user selections,appointment negotiation system 104 may indicate which second users haveyet to respond, if a majority consensus on an appointment time has beenreached, if a particular appointment time can be ruled out, or ifvarious counter offer appointment times are lining up, indicating to thefirst user (e.g., organizer) that the appointment times should beincluded in a subsequent round of counter offers, etc.

In one embodiment, the second user selections may include feedbackrelating to each appointment time that was proposed. Referring todisplay 930 of FIG. 9D, a second user may specify, for each proposedappointment time, a preference. For example, in FIG. 9D, the second usermay specify for appointment time 932 that the time is ideal (representedby two checkmarks), that appointment time 934 is okay (represented byone checkmark), and that appointment time 936 is not okay (representedby an X).

As one example, the first user may receive a push notification viadisplay 940 of FIG. 9E, indicating that a second user is unavailable forthe appointment at the selected times. The push notification may alsoindicate if the second user has included one or more counter offerappointment times. The first user may receive such a notification oncethe second user has made the indication, or may be provided as one of anumber of responses provided at step 808 at once. The first user maythen decide to either ignore the suggestion, create a counter offer withnew proposed appointment times, or create an addition to the currentappointment invitation with the new appointment times. The new orrevised appointment invitations may then be sent out to the plurality ofsecond users.

The first user may eventually select a single appointment time for theappointment. Process 800 may include receiving the selection, andtransmitting an indication of the selection of the appointment time tothe plurality of second remote devices (step 810). For example, step 810may include sending a push notification such as that shown in display950 of FIG. 9F. Step 810 may further include various activities relatedto user app module 207 operation. For example, user app module 207 mayreceive the notification and update and synchronize with a calendarapplication of the remote device, may delete unused appointment timesfrom the calendar, etc.

Process 800 further includes synchronizing the appointment with eachremote device (step 812). For example, if a second user later cancelshis or her appointment, all other users may be notified and the calendarentry for each user may be updated. As another example, if a first userchanges the appointment details, all second users may be notified andthe calendar entry updated.

Appointment Negotiation Server

Referring now to FIG. 10, appointment negotiation system 104 isdescribed in greater detail. Appointment negotiation system 104 may beconfigured to execute the systems and methods described herein,particularly processes 400, 600, 800. The possible variations onone-to-one scheduling and group scheduling methods as described inprocesses 400, 600, 800 may be implemented by appointment negotiationsystem 104 as additional or alternative steps in processes 400, 600,800, according to varying embodiments of the present disclosure.

Appointment negotiation system 104 includes a processing circuit 1002including a processor 1004 and memory 1006. Processor 1002 may beimplemented as a general purpose processor, an application specificintegrated circuit (ASIC), one or more field programmable gate arrays(FPGAs), a group of processing components, or other suitable electronicprocessing components. Memory 1004 is one or more devices (e.g., RAM,ROM, flash memory, hard disk storage, etc.) for storing data and/orcomputer code for completing and/or facilitating the various user orclient processes, layers, and modules described in the presentdisclosure. Memory 1004 may be or include volatile memory ornon-volatile memory. Memory 1004 may include database components, objectcode components, script components, or any other type of informationstructure for supporting the various activities and informationstructures of the present disclosure. Memory 1004 is communicablyconnected to processor 1002 and includes computer code or instructionmodules for executing one or more processes described herein.Appointment negotiation system 104 further includes a network interface1008 for wirelessly communicating with one or more remote devices.

With respect to the description below, “first user” and “first remotedevice” relates to a user creating an appointment invitation, and“second user” and “second remote device” relates to one or more usersbeing invited to an appointment by the first user.

Memory 1004 may include a one-to-one scheduling module 1010 and groupscheduling module 1030. Modules 1010, 1030 may be configured to handleone-to-one scheduling and group scheduling services of service 104,respectively. Memory 1004 may receive an initial first user input from afirst remote device. Memory 1004 may determine whether the initial userinput relates to an appointment invitation including one other user ormultiple users, and may determine the correct module 1010, 1030 to use.

One-to-one scheduling module 1010 is shown to include a calendar appmodule 1012. Calendar app module 1012 may be configured to provide auser app module of a remote device (e.g., user app module 207 of remotedevice 102) with calendar application data. The calendar applicationdata may be used by the user app module to generate a user interface fora user of the remote device that displays calendar-related information.For example, the calendar application data may include a title anddescription for a proposed appointment, all proposed appointment times,the person sending the invitation, the location of the appointment, ifthe appointment is recurring, etc. Module 1012 may send calendarapplication data such that the user app module may create a calendarentry for each proposed appointment time. Each calendar entry may bemarked as “tentative” (and marked, shaded yellow, or otherwisedistinguished as such in the app) until the corresponding appointmenttime is confirmed or denied. In one embodiment, calendar app module 1012generates calendar application data for the second remote device whilethe user app module of the first remote device may create calendarapplication data based on the initial invitation. In another embodiment,calendar app module 1012 may generate calendar application data for bothremote devices.

When appointment negotiation system 104 receives an acceptance of anappointment time or denial from either remote device, calendar appmodule 1012 may be configured to send the appropriate calendarapplication data to update calendar entries (e.g., to remove calendarentries for unselected times, to change statuses from “tentative” to“confirmed,” etc.).

Module 1010 further includes push notification module 1014. Pushnotification module 1014 may be configured to generate a pushnotification that appears on a remote device of a user. For example, thepush notification may simply be a window including a message indicatingthat a first user has invited the second user to an appointment. Asanother example, the push notification may be a window including amessage that a second user has accepted, declined, or counter-offered anappointment invitation. The push notification may include any number ofinput fields (e.g., selectable buttons) that allows the user to selectappointment times, accept or decline invitations, and the like.

Module 1010 further includes counter offer module 1016, which may beconfigured to manage a counter offer of a first user or second user. Forexample, when a second user makes a counter offer to an appointmentinvitation, module 1016 may receive the request and correspondinginformation (e.g., a message from the second user, proposed appointmenttimes, etc.). Module 1016 may be configured to provide the informationto calendar app module 1012 so that module 1012 may update calendarentries of both users, and to push notification module 1014 to send apush notification to the first user. As another example, module 1016 maymanage a second counter offer from the first user in a similar manner.

Module 1010 further includes a non-user module 1018. Non-user module1018 may be configured to handle communication with a second remotedevice that does not include a user app module. Non-user module 1018 maybe configured to receive an appointment invitation from the first userand to generate a text message, email, or other message to send to thesecond user. For example, the message may be a text message that thesecond user can reply to in order to accept or decline an appointmentinvitation, along with selecting an appointment time. As anotherexample, the message may be an email with a link to a website. The website may then include a user interface that allows the second user toaccept or decline an appointment invitation, along with selecting anappointment time. The email may also include a link to download a userapplication that may execute or install the user app module on theremote device of the user.

Group scheduling module 1030 is shown to include a calendar app module1032. Calendar app module 1032 may have functionality similar tocalendar app module 1012, but may serve a plurality of second remotedevices instead of a single remote device. Therefore, calendar appmodule 1032 may be additionally configured to send calendar applicationdata for other second users of second remote devices.

For example, when a second user provides an input relating to theappointment invitation, the input may relate to user availability foreach of the appointment times. Calendar app module 1032 may beconfigured to send an update to each of the second users relating to theuser availability. For example, if one user indicates that he or shecannot make an appointment for a given appointment time, the informationmay be sent to other users so that they can see that the user cannotmake the given appointment time. In one embodiment, calendar app module1032 may be configured to send such updates each time a user providesinformation, at regular given intervals, or on any other type ofschedule.

Module 1030 further includes a push notification module 1034. Pushnotification module 1034 may be configured to generate a pushnotification that appears on a remote device of a user. For example, thepush notification may simply be a window including a message indicatingthat a first user has invited multiple second users to an appointment.As another example, the push notification may be a window including amessage that a second user has responded to the appointment invitationby indicating preferences to each appointment time. The pushnotification may include any number of input fields (e.g., selectablebuttons) that allows the user to select appointment time preferences,decline invitations, and the like. In one embodiment, push notificationmodule 1034 may provide a push notification to each user after a singleuser responds to the appointment invitation. In another embodiment, pushnotification module 1034 may provide push notifications at scheduledintervals instead, or on any other timetable, such that the plurality ofsecond users do not receive continuous updates.

Module 1030 further includes a counter offer module 1036. Counter offermodule 1036 may be configured to manage a counter offer of a seconduser. For example, when a second user makes a counter offer to anappointment invitation, module 1036 may receive the request andcorresponding information (e.g., a message from the second user,proposed appointment times, etc.). Module 1036 may be configured toprovide the information to the first user, and the first user may ignoreor respond to the counter offer accordingly.

Module 1030 further includes a non-user module 1038. One or more of thesecond users may use a remote device without a user app module. Non-usermodule 1038 may be configured to handle communication with a secondremote device that does not include a user app module. Non-user module1038 may be configured to receive an appointment invitation from thefirst user and to generate a text message, email, or other message tosend to a second user. For example, the message may be a text messagethat the second user can reply to in order to vote on or rankappointment times of the appointment invitation. As another example, themessage may be an email with a link to a website. The website may theninclude a user interface that allows the second user to vote on or rankappointment times of the appointment invitation, make counter offers,etc.

Module 1030 further includes second user reply module 1040. Module 1040may be configured to receive the various user replies and to analyze andsort the data. For example, each user may provide, for each proposedappointment time, an indication that the time is ideal for the user,that the time is okay for the user, that the time is not good for theuser, or another indication. Module 1040 may receive the indication foreach appointment time. Module 1040 may further aggregate the indicationsto determine a most ideal appointment time, an appointment time thatshould be discarded, and so forth. Module 1040 may, in one embodiment,assemble the various indications into a table format for presenting to afirst user and plurality of second users. Module 1040 may also organizevarious counter offers in various ways to offer the first user moreappropriate counter offer options to offer the other users in the group.For example, if three other users have indicated a common counter offerappointment time, module 1040 may indicate the appointment time to thefirst user and suggest the first user incorporate the appointment timein a counter offer to the group of users.

As another example, each user may rank each proposed appointment timefrom best to worst, and module 1040 may be configured to aggregate thevotes to determine an average ranking or a most desired appointmenttime.

Module 1030 further includes boss mode module 1042. In one embodiment,during group scheduling, a first user may send invites to a plurality ofsecond users, but one or more of the second users may have higherpriority than the other users (e.g., they may be bosses or supervisors,essential personnel for the appointment, etc.). Boss mode module 1042may be configured to receive a response from the higher priority usersand determine when an update should be sent to the first user and/orother less important second users. For example, a supervisor may respondto an appointment invitation by indicating his or her preferredappointment times. Boss mode module 1042 may receive the supervisorinput and determine that one or more appointment times that conflictwith the supervisor should be removed, that a particular appointmenttime should be chosen by the first user based on the supervisor input,etc. In one embodiment, the supervisor may override other users'decisions and set an appointment time himself or herself, and boss modemodule 1042 may be configured to alert the other modules of module 1030.In another embodiment, the supervisor may receive the appointmentinvitation before the other invitees receive the invitation. Thesupervisor may approve the appointment invitation for sending to otherusers, the supervisor may edit the appointment times, approve or deleteindividual appointment times, or may otherwise edit, approve, ordisapprove any aspect of the appointment invitation before theinvitation is sent to the other second users.

Appointment negotiation system 104 and memory 1004 is shown to furtherinclude a database 1050. Database 1050 may be configured to store datarelated to the appointments and users. For example, database 1050, for agroup scheduling process, may be configured to store the votes of eachsecond user (e.g., a status for each appointment time submitted by eachuser), a timestamp indicating when the second users voted, and othersecond user data to be transmitted to a first user data before the firstuser selects an appointment time. Database 1050 may further store anindication if a second user has viewed or responded to the appointmentinvitation yet. Database 1050 may be configured to store all data thatmay be transmitted to and from appointment negotiation system 104 asdescribed with reference to modules 1010, 1030, and their sub-modules.

It should be understood that while various modules are shown inappointment negotiation system 104, one or more of the modules mayadditionally or alternatively be a part of user app module 207 of aremote device 102, such that the activities described may be performedby the remote device instead of appointment negotiation system 104.

In the embodiments of FIGS. 4-10, a first remote device is generallydescribed as a mobile device, while the second remote devices may bemobile devices or non-mobile devices. In another embodiment, the firstremote device may be a non-mobile device, and the first remote devicemay include a user app module configured to handle the activitiesdescribed herein.

User Interfaces

Referring generally to FIGS. 11-32, various example user interfaces areshown and described. The user interfaces of FIGS. 11-32 may be generatedby a user app module that receives appointment information from anappointment negotiation service. The user interfaces of FIGS. 11-32 areprovided as example user interfaces and are not intended to be limitingthe possible configurations and presentation of the appointmentinformation as shown.

Referring to FIG. 11, user interface 1100 may be used by a first user ofa first remote device (e.g., an inviter) to create or edit anappointment. The user may access user interface 1100 when first creatinga meeting, or editing an existing meeting. The user is provided withvarious fields on user interface 1100 related to the appointment. Theuser may change a name or title for the appointment in field 1102. Theuser may change a duration (e.g., how long the appointment will last)using fields 1104. The user may set one or more alarms using fields 1106that will remind one or all users about the appointment beforehand(e.g., 15 minutes before the appointment as shown in FIG. 11). The usermay specify a type of appointment in field 1108. For example, the usermay specify that the appointment is casual, is a work meeting, is asocial gathering, phone call, online presentation, etc. The user mayfurther specify how to categorize the appointment, or which of theusers' calendars to write the appointment into (by category or bycalendar application, etc.) using field 1108. The user may specify isthe appointment should be recurring using field 1110 (e.g., if themeeting occurs every day, every week, every month, every year, etc.).The user may specify who is invited to the appointment using field 1112.The user may specify the three (or other number) of appointment times topresent to the other users being invited to the appointment using fields1114. For example, three times are illustrated as being proposed in userinterface 1100. The user may cancel the creation or editing of theappointment via button 1116, and may create, edit, save, and/or send theappointment using button 1118.

Referring to FIG. 12, user interface 1200 may be a calendar interfacegenerated by a user app module using retrieved calendar data. Userinterface 1200 includes multiple appointments 1202, 1204, 1206. Theappointment information shown with appointments 1202, 1204, 1206 mayinclude the other users invited to the appointment, a status of eachuser (e.g., a question mark indicates the user is tentatively joiningand the checkmark indicates the user has verified he or she willattend), a name and meeting location of the appointment, or otherinformation. In one embodiment, each meeting may be color coded suchthat the user may identify the type of appointment (e.g., work, social,etc.) or which third party calendar service the appointment will bewritten to. User interface 1200 is an example user interface that may begenerated when a user wishes to view his or her calendar.

Referring to FIG. 13, user interface 1300 is another calendar interfacethat may be generated by a user app module using retrieved calendardata. User interface 1300 includes multiple appointments 1202, 1204,1206 displaying the same information as described with reference to FIG.12. However, in addition, other user interface elements are shown.Element 1306 is shown in a blank space in the user's schedule. Element1306 may indicate to the user that this particular time period (2 PM inthe example of FIG. 13) is open and that the user may schedule anotherappointment in the time slot without interfering with otherappointments. Element 1308 is also shown within appointment 1307.Element 1308 may indicate to the user that this particular time period(3 PM in FIG. 13) was originally open for the user but has been selectedby the user as a possible time for a one-to-one or group appointment.Elements 1306, 1308 may be color coded to indicate a particular status.For example, elements 1306, 1308 may be color coded to represent thatthe time if available or empty, indicating to the user that the time isavailable for the appointment. In other embodiments, elements 1306, 1308may indicate the times are part of the user's work schedule, that thetime is not part of the user's work schedule, or otherwise. This mayassist the user in decision-making when it comes to choosing appointmenttimes.

Referring to FIG. 14, user interface 1400 is another calendar interfacethat displays a calendar. User interface 1400 may allow the user tonavigate in between dates while in the appointment negotiation process.Dates 1402, 1404 are shown as color coded dates, which may generallyrepresent availability and other properties. A user may view interface1400 to see which days he or she is scheduled for an appointment.

Referring to FIG. 15, user interface 1500 is another calendar interfacedisplaying three appointments 1502, 1504, 1506. User interface 1500 maybe displayed on a second remote device. The second remote device mayreceive an invitation to an appointment, shown as appointment 1506.Appointment 1506 is shown as shaded in user interface 1500, indicatingthe appointment as tentative. Appointment 1506 includes an accept button1508 that will accept the appointment at the given time (3 PM) ifselected. Appointment 1506 also includes the one or more other users1510, along with an indicator of how many users are invited and/or howmany users have replied, and may include other appointment information.

In addition to presenting the appointment in field 1506, alternativetimes for the appointment may be displayed at the bottom of userinterface 1500. The user may select the first time 1512 of 3 PM, thesecond time 1514 of 2 PM on another day, or a third time 1516 of 9 PM ona third day. When the user selects one of times 1512, 1514, 1516, thecalendar may automatically shift appointment 1506 displayed above intothe new time slot on the calendar. For example, as shown, the user mayhave selected time 1512. User interface 1500 further includes a cancelbutton 1518 that allows the user to cancel or decline the appointment.

Referring to FIG. 16, user interface 1600 is another calendar interfacedisplaying three appointments 1602, 1604, 1606. User interface 1600 maybe displayed on a second remote device. The second remote device mayreceive an invitation to an appointment, shown as appointment 1606.Appointment 1606 is shown as shaded in user interface 1600, indicatingthe appointment as tentative. Appointment 1506 includes an element 1608that may designate the particular time (3 PM in FIG. 16) as busy, open,a working time, or any other type of designation. Use interface 1600further includes times 1612, 1614, 1616 and button 1618, which have thesame functionality as described with reference to times 1512, 1514,1516, and button 1518 of FIG. 15.

Referring to FIG. 17, an example invite list is shown in user interface1700. When a first user is first setting up an appointment, the user mayselect invitees from a list of friends via button 1702, via a list ofother users who have the same user app module via button 1704, or anyother list of users including but not limited to contact from the user'sdevice. The user may select button 1706 to send out the invites toselected users.

One user 1708 is shown with a check marked element 1710, indicating theuser has been selected. Another user 1712 is shown with an invite button1714 that the user may press to select user 1712.

Referring to FIG. 18, user interface 1800 displays another calendarapplication. User interface is shown to include a weekly view, andillustrates various appointments. The appointments may be color coded,according to various embodiments. For example, appointment 1802 may beshaded blue to indicate a social appointment. Appointment 1804 may beshaded green to indicate a work-related appointment. Appointment 1806may be shaded red to indicate a personal appointment.

Referring to FIG. 19, user interface 1900 illustrates a notificationlist. When a second user responds to an appointment invite, userinterface 1900 may be configured to display a notification to the firstuser about the response. For example, notification 1902 indicates thatthe second user has accepted an appointment invitation at a particulartime and date. Notifications may continue to be listed on user interface1900, and the user may clear the list, respond to a particularnotification, etc.

Referring to FIG. 20, user interface 2000 illustrates an example pushnotification 2004. Push notification 2004 may pop up after another userhas accepted an appointment invite. The user may confirm the appointmentvia button 2008, or may cancel or edit the appointment via button 2006.Also illustrated in user interface 2000 is alert 2002. Alert 2002 maypop up on user interface 2000 after a user sends out an appointmentinvitation.

Referring to FIG. 21, user interface 2100 illustrates anothernotification list. Compared to user interface 1900 of FIG. 19, userinterface 2100 may be a user interface on a second user's remote device,indicating to the user that he or she has received an invitation to anappointment. Notification 2102 may indicate the person who send theinvitation, along with a title, location and other information,including the proposed appointment times.

Referring to FIG. 22, user interface 2200 illustrates a method ofselecting an appointment time. User interface 2200 may be provided on,for example, a remote device of a second user. Three possibleappointments 2202, 2204, 2206 are displayed on user interface 2200 forthe user to view. At the bottom of user interface 2200, the three times2208, 2210, 2212 corresponding with appointments 2202, 2204, 2206 areshown. The user may select an appointment to approve either viaselecting an appointment 2202, 2204, 2206 or selecting a time 2208,2210, 2212. The user may confirm the selection via button 2214, orcancel the appointment via button 2216.

User interface 2200 is shown as an example of a contextual view of theappointment. The appointment may be received by the remote device, andmay be used to populate the calendar with an entry for the appointmentfor each appointment time. The user may then choose an appointment time,vote on the appointment times, or otherwise interact with theappointments using the calendar application as shown in FIG. 22, withoutusing a separate application. In FIG. 22, user interface 2202 ishighlighted in yellow, orange or through a pattern 2203 as shown in timeslot 3:30 PM. The highlighting or the indication allow the user to showthat one of the selections could occur at 3:30 PM. Similarly, the nextsuggested time may be 5:00 PM and it may be highlighted. 7:00 PM mayalso be highlighted.

Referring to FIG. 23, user interface 2300 illustrates a feature of groupscheduling available to the inviter (e.g., the first user). Userinterface 2300 may be used to display user responses to a plurality ofproposed appointment times (11 AM, 1:30 PM, and 6 PM as shown in FIG.23) for an appointment 2302. A plurality of users 2304-2316 are shown ashaving responded to each proposed appointment time.

The user may select, for each time, whether the appointment time isideal, okay, or not okay. In one embodiment, two checkmarks mayrepresent ideal, one checkmark may represent okay, and an X mayrepresent not okay. The user may view the various responses on userinterface 2300 and select a best time based on the responses.

Referring to FIGS. 24-25, user interfaces 2400, 2500 may be providedwhen a first user is setting up a new event or appointment. Userinterface 2400 may be an expanded view of options available to the firstuser when setting up the appointment, which user interface 2500 may be acollapsed view of options available. User interface 2400 is shown toinclude an event information section 2402, event detail section 2410,and collaboration option section 2420 are shown. In event informationsection 2402, the first user may provide a title 2404 for theappointment, a location 2406 of the appointment, and contact information2408 for the appointment. For example, if the appointment is a meetingin a conference room that other users may call in to participate, thefirst user may specify such contact information in field 2408.

The first user may, in event detail section 2410, identify a desiredstart time 2412 of the appointment, and a duration 2414 the appointmentwill be scheduled to last. The first user may further a calendarapplication 2416 to send the invitation to and an alarm 2418. Alarm 2418may be used to alert the first user at a set time before the appointmentthat the appointment is about to begin.

The first user may, in collaboration option section 2420, specify one ormore users to invite to the appointment in field 2422. The first usermay also specify other alternative start times for the appointment toprovide as options to the other users. The first user may also provideother notes 2426 or information related to the appointment to send tothe other uses. The first user may further specify a type of appointmentby selecting one or more of buttons 2428. For example, the first usermay specify if the appointment will be held via a phone call, if theappointment will be held over lunch, dinner, coffee, drinks, etc., if itis an in-person meeting, etc. When done, the first user may confirm theappointment via button 2430, or the first user may cancel theappointment via button 2432.

In user interface 2500, a collapsed version is shown that illustrates anevent information section 2502, indicating a selected title 2504,location 2506, and contact information 2508 (e.g., a phone number todial). The first user may view user interface 2500 to verify thecreation or editing of the appointment. User interface 2500 furtherincludes elements 2510 that indicate a selected type of appointment. Thefirst user may verify the appointment via button 2512 or cancel theappointment via button 2514.

Referring generally to FIGS. 26-29, user interfaces are shown thatillustrate various method of displaying notification information.Notification information may generally include a list of three differenttypes of notifications: notifications that a user has to respond to,notifications indicating that another user has to respond, andnotifications that indicate that an appointment has been booked orfinalized. Notification information may be assembled as generally shownin FIGS. 26-29 to organize all notifications for a user into a singlescreen, for easier viewing.

In user interface 2600 of FIG. 26, the user may view a list ofnotifications that require a response from the user (indicated byelement 2602). The list of notifications 2604, 2606, 2608, 2610, 2612may include an identification of the user awaiting the response, thetitle of the appointment, and a time at which the notification arrived(e.g., when the other user sent the notification. User interface 2600may further include elements 2614, 2616, 2618 that may indicate animportance of the appointment, a particular time that conflicts with theuser or is ideal for the user, or otherwise.

In user interface 2700 of FIG. 27, the user may view a list ofnotifications that require a response from another user (indicated byelement 2702). The list of notifications 2704, 2706, 2708, 2710, 2712may include an identification of the one or more users that need torespond, a title of the appointment, an organizer of the appointment,and a timestamp indicating when the request for a response was sent.User interface 2700 may further include elements 2714, 2716, 2718, 2720,2722 that may indicate an importance of the appointment, a particulartime that conflicts with the user or is ideal for the user, orotherwise.

In user interface 2800 of FIG. 28, the user may view a list ofnotifications that were generated based on an acceptance or booking ofan appointment (indicated by element 2802). For example, notifications2804, 2806, 2808, 2810, 2812 are booked appointments.

Notifications 2804, 2806, 2808, 2810, 2812 may indicate the appointmenttitle, organizer (first user), and a time at which the appointment wasbooked or finalized. User interface 2800 may further include elements2814, 2816, that may indicate an importance of the appointment, aparticular time that conflicts with the user or is ideal for the user,or otherwise.

Referring to FIG. 29, user interface 2900 may be a display similar touser interface 2700 of FIG. 27, displayed on a mobile device.

Referring to FIG. 30, user interface 3000 may be used by a second userin order to vote on possible appointment times in a group schedulingprocess. User interface 3000 includes calendar entries 3002, 3004 thatare created when the user is sent the appointment invitation. Calendarentries 3002, 3004 are marked as tentative until the appointment time isfinalized. User interface 3000 further includes a second portion 3006 inwhich the user may provide feedback for specific appointment times. Forexample, for each appointment time 3008 listed, the user may tap thebutton for the appointment time to change a status (ideal, okay, can't,or another status). When finished, the user may finalize his or herselections by tapping button 3010. The user may further view who elsehas been invited via tapping button 3012. By tapping button 3012, a listof other users may be presented, along with the voting results of theother users if they have already voted on the appointment times. Theuser may further decline the invitation by tapping button 3014 orpostponing making a decision on the appointment by tapping button 3016.Calendar entry 3005 may reflect an existing appointment that exists inthe user's calendar application (e.g., Outlook, iCal, Google Calendar,etc.). If entries 3002, 3004 were in conflict with entry 3005 or anotherexisting calendar entry, an indication of the conflict may be made tothe user of the remote device. Calendar entry 3002 may be highlighted,use a different color that indicates the current voting status.

Referring to FIG. 31, user interface 3100 may be a user interfaceprovided to a user wishing to view appointment details. User interface3100 includes a field 3012 that includes a title and description of theappointment, along with the date of the appointment. User interface 3100further includes a field 3104 that indicates a calendar application inwhich the appointment has been entered into. User interface 3100 furtherincludes a contact field 3106 indicating an inviter (e.g., first user)to contact about the appointment and a contact field 3108 that relatesto the inviter. User interface 3100 further includes location field 3110that identifies the location of the appointment, and may include a mapor other visual or direction information. User interface 3100 furtherinclude field 3112 which may allow the user to see others' votes onpotential appointment times.

Referring to FIG. 32, user interface 3200 includes a first section 3202and second section 3204. Sections 3202, 3204 may be similar to userinterfaces 2000, 2100 as described above. In the embodiment of FIG. 32,sections 3202, 3204 may be displayed side-by-side for the user.

Referring to FIG. 33, another user interface 3300 is shown that includesa calendar application. In the embodiment of FIG. 33, an appointment hasbeen sent to a user, and the calendar application of the user or a thirdparty calendar populates the calendar with three separate appointments3302, 3304, 3306 representing the three possible appointment times thatwere proposed. At the bottom of user interface 3300, the user may selectone of the three appointment times 3308, 3310, 3312 for the appointment,or the user may select the desired appointment from the calendar above.The user may further decline the invitation via button 3314 or postponea decision on the appointment via button 3316. The contextual view inFIG. 33 allows to user to realize that there are two 4 pm appointmentsand further the conflicting appointment may be highlighted or filledwith a patter to show the context to the user. The context allows theuser to make an appropriate selection.

Embodiments include a group scheduling system to facilitate meetings(in-person or remote). Embodiments eliminate the typically painfulback-and-forth scheduling process and transform the meeting negotiationprocess into a sleek, elegant, mobile decision-making platform.Scheduling is unnecessarily painful and may require multiple e-mailsback and forth among various groups of individuals. Embodiments reinventhow people schedule meetings using mobile devices and other devices.Implementations allow social interaction have the necessary structure toallow real plans to form and solidify. Implementations allow users tosetup a group based chat as well as an event based chat. In someembodiments, the user doesn't have to create an event with people, butrather the user creates a group and then one or more users adds plans ata later time. Accordingly, embodiments allow a user to start a groupchat without a scheduled plan. Each of the one or more plans includes atime and location information.

In various implementations, the system described herein allows a user(organizer) to invite someone or a group of people with a quick messageregarding a meeting or an event. The user may suggest a plan with aspecific time and place or multiple plans with different or same time orlocation. Alternatively, the user may suggest a plurality of plans withdifferent times and different places. The users may vote for their mostpreferred plan. The user may vote by selecting a button to indicateapproval or selecting an option to indicate disapproval. In otherembodiments, the users may send text messages to the group of invitees.The user may suggest different locations and each of the other users mayvote to indicate their preferences. Each user may provide commentsregarding each plan, the input may include location preferences, linksto ratings sites (e.g. Yelp®, Google®, etc.) or user ratings. In someembodiments, the users each may rate the location to allow the organizerto choose the appropriate plan to book. After or before receiving eachuser's input the organizer may book the event and enjoy their meeting atthe booked location. In various embodiments, the users may chat with allof the invitees relating to the event. Each event or meeting may have achat screen, so the user does not have to look up the contactinformation for each user that is invited. Accordingly, when the user isnot going to arrive on time or the user is late, the user can inform allof the invitees regarding their status via a text message that isconnected to the event.

Friends and colleagues may use various embodiments to maintainrelationships and cultivate those relationships. Groups may want toschedule in-person and local meetings. Using various embodiments allowspeople to get together and give people back those valuable seconds,minutes and hours of planning. Embodiments are directed to time andplace combinations using chat-based communication. So you're reallyvoting on a set plan vs. time and place being independent of each other.In other embodiments, phone calls may be used to schedule meetings. Anymeeting or event may include either a time and geographic location (avenue or a street address) or a time and virtual location (phone calls,Skype, webinars, anything where people are connecting synchronously).Each of the above decisions and voting between users may occur usingmessaging. Embodiments comprise consensus scheduling through mobilemessaging. Chat with local meetings, but not limited to, local meetingbecause other modalities like scheduling a Skype call, FaceTime®, videochat or phone call may be performed. Embodiments are directed toscheduling event via SMS, chat and appointment negotiation throughmessaging and voting.

Various embodiments include using a mobile device as a hub to schedulemeetings or events or group meetings or events through mobile messagingand/or chat provided by the application. Embodiments allow a user tosend text messages back and forth but also to send potential meetingtimes and meeting places within the same system and the for the samemeetings. These meeting places and times shown in the messaging systemalso propagate to a screen that allows all users of the system to see asnapshot of all the available times and places where the user can votefor or against any particular time and/or place. These may be timesand/or places combinations or individual times and individual places.Users of the system can indicate their preferences so the organizer canbook the final time based on the votes or the organizer's preference.The system allows non-users to respond via text message and via a mobilewebpage for the event. All booked appointments synchronize back to theuser's calendar whether iCal, Google, Exchange, etc. The messagingbecomes a channel for communication and negotiation. The system mayprevent users from seeing other user's calendar availability but thesystem may be permitted to access other user's calendars. Users cansuggest times that are most agreeable and the system can acknowledgewhether the second user will be free or busy during the suggested time.

Various embodiments include structured and unstructured methods ofcreating an event or meeting. Embodiments allow the user to start byinviting some people with a simple message to a group chat. In variousembodiments, the group chat is an event based group chat (title or notitle, and that is a difference between email with title and SMSswithout titles).

Embodiments comprise purpose-driven group chat messages that have anability to allow the user to add a plurality of formal plans.Embodiments include a platform that receives as input a plurality ofplans and narrows the plan down via a decision making process to abooked plan from among a plurality of plans. Various embodiments allowusers to add formal structured plans. The interactions between peoplemay be like conversations. Embodiments may store a log of the plans on astructured area of the application that the user can easily get to byclicking on the plans that popup in the chat. When the users receive astructured plan the users receive lots information that may be needed tomake a decision and vote. Information such as who is invited, who hasvoted for the different available plans, the location of each plan (withquick ability to see it on a map and receive get directions from withinthe application. The users may receive the time for each plan (with theunique ability to quickly see their calendar within the application sothe user can check their availability). Get other “venue-related” infosuch as, menu, third party ratings, etc. The user can view if thelocation is a virtual location and it is a phone call, the user can getall the dial-in information so they don't have to manually dial and thesystem will input the pin number or meeting number in for the user afterdialing the number.

Embodiments allow a user to vote and/or poll structured information thatincludes time and/or location scheduling. Event-based chat is availableas long as the event has not occurred. The chat messages continue to beavailable to the user until the event time has passed. Once the eventhas ended the chat messages may be archived to be retrieved later. Inother embodiments, the mobile device may include a plan mode. In theplan mode events may be allowed within group-chats. Accordingly, in someembodiments the system may include group-based chat and a plan mode.Thus you could be in a long group chat and someone in the group may tryto schedule an event with this group. When the user attempts to schedulean event or a meeting the mobile device may enter the group plan mode.In plan mode, the chat would be group but the planning elements wouldall be available in plan mode. This embodiment allows scheduling throughgroup chat and not just scheduling through event chat.

FIG. 34 is the event set-up screen 3400. In field 3410 a user can addthe names of the invitees that a user wants to invite to the event ormeeting. In some embodiments, field 3410 may receive telephone numbers,e-mail address, or other contact information for the invitees. To assistthe user the field may display a guidance message such as “Who do youwant to meet?” When the user selects the field 3410 the guidance messagemay be removed from the field. Title field 3420 is the optional title ofthe event or a title for a group of people in a chat scenario. A usermay type in any title possible. In some embodiments, the memory of thedevice or application may recall the previous events that the user hastyped in and search and provide the names of the previous events as anoption for the current name. In some embodiments, the title may be autofilled into the title filed. In yet other embodiments, a list of defaulttitles may be shown to the user after the user selects the title field3420. The user can choose to change the title of the event at a latertime event after the event has been booked. Each of the invitees may beinformed regarding the change of title via push message, text message oran updated web page. In some embodiments, the title field 3420 may beleft empty and the user may input the title at a later. Field 3430 is afield that allows the user to choose a date and time for a first planfor the event. Selecting the field 3430 may also open a time andlocation selection screen. After selecting the field 3430 the user mayadd the time and location of the event.

FIG. 35 is a display screen 3500 that may be displayed after the userselects field 3410 in screen 3400. In screen 3500 the user may haveselected invitees shown in area 3520. In the example shown in screen3500, the user may select additional invitees such as “Charles Francis”3530. The user may have selected two invitees, for example, “HunterGray” and/or “Linda Lee”. In some embodiments, the list of proposedinvitees may be from the user's mobile device's contact information. Inother embodiments, the list of invitees may be generated based on athird party contact provider. In some embodiments, the mobile device mayreceive the user's authentication information (login and/or password)for social networks (e.g., Facebook®, LinkedIn®, Google+, etc.). Afterreceiving the authentication information the mobile device may use theAPI to access the contact information of various additional contactsthat may or may not be stored on the contact information on the mobiledevice. In some embodiments, users that have already been registered tothe application are identified with an indication “chat+k”. The mobiledevice may communicate with a server computer to determine which of thephone numbers or e-mails of the invitees has been previously registeredwith the client application on the mobile device. When a user haspreviously registered the user receives push notification through theapplication platform, or text messages based on the selected settings.Users that have not previously registered receive message through theSMS, or text message platform. In various embodiments, the servercomputer determines the method of communication based on previousregistered user lists. Area 3520 indicates who has been added to theinvitation list. Contacts 3530 and 3540 identify persons from the user'slist of contacts that may be potentially added to the invitee list.

FIG. 36 shows a screen 3600 that allows a user to choose a date and timefor the meeting or event after the user selects field 3430 from FIG. 34.The screen 3600 allows a user to choose to view a monthly, weekly ordaily view. The user may choose a date in the calendar view 3605 and theuser may select a time in the time area 3610. In the example shown inFIG. 36 the user may be able to choose the date in area 3610 and thechosen date may be shown on the calendar. The user is offered a userinterface to select a date and time from the screen 3600 for the event.As discussed in greater detail below the user may be provided the optionto select multiple different times or for a single event.

FIG. 37 is the daily calendar screen 3700. Screen 3700 shows the mobiledevice of the user calendar for the selected date and shows all eventsoccurring on the date selected. In some embodiments, the daily calendarscreen may show the events planned by the appointment system 104. Inother embodiments, the events may be show events that have been planned,but are not booked. In various embodiments, some tentative plans may beremoved from the calendar once one of the plans related to the event arebooked. Screen 3700 shows the date 3710 at the top of the screen. Otherappointments may be shown on screen 3700.

FIG. 38 is the location choice screen 3800. The appointment system usesthe mobile device's geo-location to search nearby restaurants, bars,conferences centers, sporting events, concerts, entertainment sites,festival or local event. The user may select the venue location 3802button to access the mapping functions of the mobile device. Locationindicator 3804 shows the users present location. Other locations 3810,3820, and 3830 that may have been previously selected by the user may beshown on screen 3800. The user may select any one of the previouslyselected locations. The user may select one or more of these venues tosuggest an event location to meet with the invitees selected in FIG. 35.

Once a location is selected, FIG. 39 shows a display 3900 that shows amap view of the selected event location. Screen 3900 also displays a map3910 that displays the location of the restaurant. The user can chooseto get directions by selecting the get direction button 3920. The mobiledevice's navigation software may navigate the user to the location forthe event. In various embodiments, the address information for thelocation of the meeting may be communicated from the appointment systemto the navigation system of the mobile device.

FIG. 40 shows the selected event location's information including theirstreet address, phone number, menu, reviews, and gives the user theopportunity to check-in 4040. Screen 4000 displays an image 4010regarding the location posed by the owner of the location. Anotherportion of the screen 4000 may include the name and address 4015 rating4020, map 4025, information about a venue 4030. As shown in screen 4000the user may call the location using phone number 4031, menu 4032,reviews 4033 and check-in 4040. The user is also given the option toagree to attend (by selecting the check) or deny (selecting the x)attending the event. User may then select any of these prompts to reviewfurther information pertaining to the selected location.

FIG. 41 is the plan screen display 4100. Screen 4100 shows the variousplans regarding the event. Plans tab 4110 may be selected by the user toview the various plans regarding an event. In the plan view, theinformation regarding a plan may be displayed with an image andinformation regarding each invitee's votes regarding a plan. The usermay select chat window button 4120. The chat window may display variousmessages that the user has sent to the group of invitees and themessages that the groups of invitees have sent to the group regardingany one of the plans. In various embodiments, each plan may have its ownlist of text messages. Check mark 4150 and mark 4160 prompts the user toselect whether or not they are planning to attend the event. The usermay select the check mark 4150 to attend the event, or the “x,” 4160 todecline. A check mark 4140 placed adjacent to the image or identifierfor each invitee identifies which invitees are attending the event anddecline indicator 4130 identifies which attendees will not be attendingthe event. Chat window 4120 takes the user to an alternate screen inwhich the user can send or receive messages with the other attendeesregarding the event. As shown on the plans screen additional locationsor plans by other individuals may be displayed. For example, screen 4100shows “Sara's plan” and “Jack's plan”, accordingly, the each invitee cansuggest their own plan to all invitees. All invitees are offered theoption to endorse each one of the plans.

FIG. 42 shows the chat screen 4200 where attendees can text back andforth in a group text with the other attendees regarding the event. Insome embodiments, this chat screen 4200 may not be included in themobile device's general text messages and is remote to this event. Asshown in screen 4200, plans from some users may appear in the chatscreen 4200 and in the plans screen 4200. Text messages, videos, images,and the like may also be shown in text messages screen. Messages may bedisplayed chronologically as they are sent. In other embodiments, eachevent or plan may be used by a server computer to generate a web page tobe displayed to users who wish to view the events status on theircomputer. In other embodiments, the text messages regarding the eventmay also be displayed on the web page generated by the server computer.In other embodiments, location negotiation among users may occur by oneuser proposing a location and other users voting for the location.

FIG. 43 displays the event list screen 4300. Screen 4300 lists all ofthe different events user is invited to, and/or is attending. Organizer4310, 4330, and 4350 are identified by a symbol displayed adjacent totheir image or picture. In the example that is shown in screen 4300 thehosts or organizers are identified by a crown symbol and also includesthe contact information or image of the event coordinator. Invitees 4320and 4330 are listed (by image or initials of their name) after theorganizer for each event. The check mark 4340, as well as their image orinitials identify the attendees. Non-attendees 4385 are invitees whohave indicated that they will not be attending the event. Thenon-attendees are identified by an “x,” as well as their contact image.Status identifiers 4370 and 4380 indicate the status of the event. Ifthe event is still in the process of coordinating the time and place ofthe event, the status will indicate, “Planning.” During this stage,several different locations 4360 and 4395 may be in the process of beingagreed upon by all of the attendees. In this case, all of the locationswill be identified under the planning stage until the event location andtime are agreed upon by at least some of the attendees. Once all of theevent details are agreed upon by at least some of the attendees and theevent location has been reserved, the status will changed be changed to“Booked” 4380. In various embodiments, a user may be able to addadditional plan from within the chat screen by typing in various keyterms that have been predetermined for the application to understand thechat message as a plan. For example, when a user types in “add plan,time, location” syntax the chat software may add a plan that includesall of the original invitee. In other embodiments, the plan may bebooked based on the number of users that have accepted and so long asthe majority of users have accepted the plan may be booked. Theorganizer always has the option to unbook or book a plan. In otherembodiments, the organizer may want to make sure that certain users willmost certainly attend or the guest of honor can attend. In variousembodiments, the organizer may provide different weightings fordifferent users. For example, the vote of one invitee may count as 2, 3,4, 5 votes to give that invitee a higher priority. In variousembodiments, unless a particular invitee accepts the invitation, a plancannot be booked. In various embodiments, when the organizer did notcreate the plan, the organizer must accept the newly submitted plan forthe plan to be booked. In various embodiments, the server system maygenerate a web page based on the event setup by the user. In variousembodiments, the booking of an event or meeting may be doneautomatically by the server computer or performed manually. The systemsdescribed here may operate in various modes, such as but not limited to,chatting, planning or booked. In the chatting mode a group of peoplehave no future plans or booked plans. When the system is in a planningmode the group of people have unbooked future plans. In the booked modethe group of people have at least one booked future plan. Once an eventis booked and the event is over, the group returns to the “chatting”state and the modes may be reset to start over again.

FIG. 44 shows a screen 4400 that may be used for a dial in meeting orevent. The user interface from screen 4400 may be used for anon-physical or virtual location with a time instead of a physicallocation and time. The user may be able to set up a meeting via a phonecall with dial-in number information. In some embodiments, once theevent has been booked, the event coordinator can select whether all ofthe attendees will call the event coordinator using option 4410. In someembodiments, the event coordinator may want to call each of theattendees using option 4420. In various embodiments, the eventcoordinator may determine that all of the attendees will call thedial-in number by selecting option 4430. If the event coordinatorchooses to use a Dial-in number 4450 the event coordinator may alsoassign a pin 4440 to the event for each of the attendees. Various typesof messaging protocols may be used to communicate between various uses.

Embodiments may include a system and a method where a user can choose toform a form a group that comprising of a plurality of members. The groupmay be formed by the user choosing to add each group member into a listof individuals using their contacts. Other users may be able to addmembers to the group. Embodiments may include sending or receiving oneor more group chat messages to or from each of the members in the group.In various embodiments, the member of the group may send one or morechat messages to group members for one or more plans for a meeting. Invarious implementations, the calendar system of each of the groupmembers may be updated based on the received chat message or update thecalendar system of each of the group members by placing a tentativecalendar event based on the received chat message. In other embodiments,the method may include tracking the geolocation of each of the groupmembers and alerting the group members when one or more of the groupmembers are in a geographic vicinity of each other.

The present disclosure describes the appointment negotiation process asoccurring between a first user on a first remote device and one or moresecond users on a second remote device. In one embodiment, a single usermay use more than one remote device during the process. For example, thefirst user may send an invitation on one device, say a smartphone, thenfinalize the appointment on another device, say a tablet, if the user isin another location. It should be understood that a user may use morethan one device throughout the appointment negotiation process. Further,a user may edit an existing appointment on a different remote devicethan he or she used to book or negotiate the appointment on originally.

The construction and arrangement of the systems and methods as shown inthe various exemplary embodiments are illustrative only. Although only afew embodiments have been described in detail in this disclosure, manymodifications are possible (e.g., variations in sizes, dimensions,structures, shapes and proportions of the various elements, values ofparameters, mounting arrangements, use of materials, colors,orientations, etc.). For example, the position of elements may bereversed or otherwise varied and the nature or number of discreteelements or positions may be altered or varied. Accordingly, all suchmodifications are intended to be included within the scope of thepresent disclosure. The order or sequence of any process or method stepsmay be varied or re-sequenced according to alternative embodiments.Other substitutions, modifications, changes, and omissions may be madein the design, operating conditions and arrangement of the exemplaryembodiments without departing from the scope of the present disclosure.

The present disclosure contemplates methods, systems and programproducts on any machine-readable media for accomplishing variousoperations. The embodiments of the present disclosure may be implementedusing existing computer processors, or by a special purpose computerprocessor for an appropriate system, incorporated for this or anotherpurpose, or by a hardwired system. Embodiments within the scope of thepresent disclosure include program products comprising machine-readablemedia for carrying or having machine-executable instructions or datastructures stored thereon. Such machine-readable media can be anyavailable media that can be accessed by a general purpose or specialpurpose computer or other machine with a processor. By way of example,such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROMor other optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to carry or storedesired program code in the form of machine-executable instructions ordata structures and which can be accessed by a general purpose orspecial purpose computer or other machine with a processor. Wheninformation is transferred or provided over a network or anothercommunications connection (either hardwired, wireless, or a combinationof hardwired or wireless) to a machine, the machine properly views theconnection as a machine-readable medium. Thus, any such connection isproperly termed a machine-readable medium. Combinations of the above arealso included within the scope of machine-readable media.Machine-executable instructions include, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing machines to perform a certain function orgroup of functions.

Although the figures may show a specific order of method steps, theorder of the steps may differ from what is depicted. Also two or moresteps may be performed concurrently or with partial concurrence. Suchvariation will depend on the software and hardware systems chosen and ondesigner choice. All such variations are within the scope of thedisclosure. Likewise, software implementations could be accomplishedwith standard programming techniques with rule based logic and otherlogic to accomplish the various connection steps, processing steps,comparison steps and decision steps.

What is claimed is:
 1. A method for scheduling events, comprising:displaying, by a mobile device for each event of at least two eventsthat are being planned, at least two proposed plans with each proposedplan of the at least two proposed plans including a correspondingproposed time and a corresponding proposed location; providing a chatscreen to allow a user of the mobile device to chat with users of otherdevices; receiving a typed chat message in the chat screen by anapplication on the mobile device; recognizing, by the application on themobile device, the typed chat message as having one or more key termsthat are predetermined for the application to understand the typed chatmessage as an additional plan for an event of the at least two events;and placing a tentative calendar event in a corresponding calendarsystem of each of the users of the other devices based on the receivedchat message.
 2. The method of claim 1, wherein the typed chat messageincludes the one or more key terms, a proposed time for the event, and aproposed location for the event.
 3. The method of claim 1, furthercomprising: displaying, by the mobile device for the event, an image ofeach invitee to the event; displaying, by the mobile device for eachinvitee that has indicated they will attend the event, a correspondingidentifier next to their image specifying that they will attend theevent; and displaying, by the mobile device for each invitee that hasindicated they will not attend the event, a corresponding identifiernext to their image specifying that they will not attend the event. 4.The method of claim 1, wherein the application provides a separate chatscreen for each event of the at least two events.
 5. The method of claim1, further comprising: displaying, by the mobile device for each eventof the at least two events that are being planned, a correspondingpicture of a corresponding host along with a symbol indicating that theyare the corresponding host.
 6. The method of claim 1, furthercomprising: receiving votes from the users of the other devicesregarding the additional plan for the event.
 7. The method of claim 6,booking the additional plan for the event once a majority of the usersof the other devices have voted to accept the additional plan.
 8. Themethod of claim 6, wherein a vote of particular user of the users isweighted greater than a vote of another user of the users in order togive the particular user a higher priority in determining whether theadditional plan is booked.
 9. The method of claim 1, further comprising:displaying, by the mobile device, a location choice screen; using, bythe mobile device, a current geo-location of the mobile device todisplay a location indicator on a map within the location choice screen;and displaying, by the mobile device, one or more other locations thathave been previously selected by the user of the mobile device on thelocation choice screen along with the map.
 10. The method of claim 9,further comprising: receiving, by the mobile device in the locationchoice screen, a selection of a location from among said one or moreother locations to suggest the location as a venue for a particularevent.